# Код-ревью

В код-ревью мы придерживаемся [правил от Google](https://google.github.io/eng-practices/review/reviewer/) в адаптации [на русском языке](https://habr.com/ru/articles/737012/), с изменениями согласно нашим внутренним правилам.

## Скорость проверки кода

Правило первое: проверка кода должна быть быстрой. 
Правило второе: проверка кода должна быть ещё быстрее. 
На код-ревью выделяются одни рабочие сутки. 
За это время PR должен или набрать два апрува, или получить внятные и не оспариваемые разработчиком указания, что нужно переделать. 
Поскольку в спринте 10 рабочих дней, задержка PR на больший срок без весомых причин может послужить причиной срыва целей спринта.

## Основополагающие принципы важнее личных предпочтений

Аспекты дизайна программного обеспечения почти никогда не являются вопросом чистого стиля или просто личными предпочтениями. 
Они основаны на основополагающих принципах и должны взвешиваться на основе этих принципов, а не просто на личном мнении. 
Иногда есть несколько допустимых вариантов. 
Если автор может продемонстрировать (либо с помощью данных, либо на основе твёрдых инженерных принципов), что несколько подходов одинаково верны, то рецензент должен принять предпочтение автора. 
В противном случае выбор диктуется стандартными принципами проектирования программного обеспечения.

## Как сделать так, чтобы необходимость код-ревью не "доставала" разработчиков?

Бывает такое, что в команде из нескольких человек на разработчика сваливается с десяток код-ревью за день. 
Если добросовестно подходить к ревью, не хватит времени на выполнение собственных задач, и команда может разделиться на разработчиков, которые пишут код и закидывают своими PR всех остальных, и остальных, которые за свалившимися на них PR не будут успевать делать свои задачи.

Мы предлагаем каждому разработчику добросовестно высчитывать, какой процент PR по команде он должен брать, по формуле:

`Персональное количество ревью = общее количество ревью / (количество разработчиков в команде - 1) * необходимое количество апруверов`

Предположим, в команде 5 человек. 
На одного члена команды пришло 10 PR. 
Для одного ревью необходимо два апрува. 
Значит, из 10 PR он должен взять `10 / (5 - 1) * 2 = 5.`

## После code-review

Мы оставляем в Git Log только один коммит для задачи. Для сделанных задач мы удаляем рабочие ветки.

Для этого, при слиянии рабочей ветки в develop, мы следуем следующим шагам:

1. Отмечаем удаление рабочей ветки после слияния.
2. Выбираем стратегию слияния Squash.
3. Осуществляем слияние.

![Слияние](media/merging.png)